Repetición en el desarrollo del software
¿Cuántas veces en los últimos 6 meses has escrito código para buscar un elemento en una colección?
Naturaleza repetitiva de la programación (ordenar, buscar, recorrer, …)
¿Por qué no es frecuente?
Dificultades técnicas y no técnicas
Dificultades técnicas
Diseñar código reutilizable es difícil.
Hacemos las mismas cosas pero no de la misma forma.
Difícil captura de las similitudes.
Permitir adaptación
Ejemplo
Rutina genérica para “búsqueda en una colección”
FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEAN
VAR
pos : Posicion;
BEGIN
pos:= Comenzar (x,c);
WHILE not Completa (pos,c) and not Encontrado (pos, x, c) DO pos:= Siguiente (pos, x, c);
buscar:= not Completa (pos,c);
END;
Requisitos de los módulos para facilitar la reutilización
1. Variación en tipos
Aplicable a diferentes tipos de elementos
x: Elemento
FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEAN
VAR pos : Posicion;
BEGIN
pos:= Comenzar (x,c);
WHILE not Completa (pos,c) and not Encontrado (pos, x, c) DO pos:= Siguiente (pos, x, c);
buscar:= not Completa (pos,c);
END;
Requerimientos de los módulos para facilitar la reutilización
2. Variación en estructuras de datos y algoritmos
El tipo Coleccion puede estar implementado de diferentes formas y Siguiente(pos,x,c) puede estar ligado a diferentes rutinas:
FAMILIAS DE MODULOS relacionados
FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEAN
VAR pos : Posicion;
BEGIN
pos:= Comenzar (x,c);
WHILE not Completa (pos,c) and not Encontrado (pos, x, c) DO pos:= Siguiente (pos, x, c);
buscar:= not Completa (pos,c);
END;
Requerimientos de los módulos para facilitar la reutilización
3. Independencia de la representación
Se puede usar una operación sin conocer su implementación
siguiente(pos,x,c), comenzar(x,c),
encontrado(pos,c), completa(pos,c)
FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEAN
VAR pos : Posicion;
BEGIN
pos:= Comenzar (x,c);
WHILE not Completa (pos,c) and not Encontrado (pos, x, c) DO pos:= Siguiente (pos, x, c);
buscar:= not Completa (pos,c);
END;
Independencia de la representación
Alternativa:
if “c es de tipo A” then
“aplicar algoritmo de búsqueda A”
elseif “c es de tipo B” then
“aplicar algoritmo de búsqueda B”
elseif …
Este código sería incluido en:
Un único módulo: Grande y sujeto a constantes cambios
Código cliente: Dificulta la extensibilidad
Requerimientos de los módulos para facilitar la reutilización.
4. Factorizar comportamientos comunes dentro de una familia de implementaciones
5. Rutinas relacionadas
FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEAN
VAR pos : Posicion;
BEGIN
pos:= Comenzar (x,c);
WHILE not Completa (pos,c) and not Encontrado (pos, x, c) DO pos:= Siguiente (pos, x, c);
buscar:= not Completa (pos,c);
END;
La operación “búsqueda” se escribe una sola vez.
Ejemplo: Factorizar comportamientos comunes
Fichero
Secuencial
Una nueva variante sólo tiene que especificar cómo implementar estas cuatro rutinas
Estructuras modulares tradicionales
Rutinas
Paquetes o Módulos
¿Por qué no son suficientes?
Posibles soluciones para darles flexibilidad:
Sobrecarga
Genericidad
¿cubre los requisitos de módulos reutilizables?
Rutinas
Unidad de software que puede llamar a otras unidades para ejecutar un cierto algoritmo.
Enfoque de reutilización: librerías de rutinas
Adecuadas en áreas donde pueden ser identificado un conjunto de problemas individuales con las siguientes limitaciones:
1. Admiten especificación simple: pequeño conjunto de parámetros.
2. No estén implicadas estructuras de datos complejas.
3. Problemas claramente diferenciados.
Limitaciones de las rutinas
Soluciones para: "Búsqueda en una colección secuencial”:
1) Una rutina:
"CASE" enorme.
Muchos argumentos.
2) Conjunto de rutinas:
Rutinas muy similares (? factorizar comportamiento)
Cliente debe buscar en un laberinto de rutinas.
Conclusión: Un módulo reutilizable debe estar abierto a la adaptación y, la única forma de adaptación de una rutina es pasarle diferentes argumentos.
Las rutinas no son suficientemente flexibles
Paquetes/Módulos
Son unidades de descomposición de software que:
Cumplen el principio de Unidad Lingüística Modular
Contienen variables y rutinas relacionadas = características del `paquete
Admiten la Ocultación de la Información (módulos abstractos)
Permite la implementación de tipos definidos por el programador
Los módulos sólo resuelven ”rutinas relacionadas”
facilita depuración y cambio al proveedor
es más fácil para los clientes encontrar y usar los servicios de los módulos
Ejemplo: Paquetes/Módulos
Package TablaEnteros;
type ArbolBinEnteros
record
info: Integer
izq, der: ArbolBinEnteros
end;
new: ArbolBinEnteros begin … end;
añadir(t:ArbolBinEnteros; x: Integer) begin … end;
existe(t:ArbolBinEnteros; x: Integer): Boolean begin .. end
….
end
(Gp:) DECLARACIÓN DE TIPO
OPERACIONES
SOBRE EL TIPO
PAQUETE
Sobrecarga
Identificador con más de un significado.
Ejemplo: Sobrecarga de rutinas
FUNCTION Búsqueda (x:Cuenta; t: ListaCuentas): Boolean;
FUNCTION Búsqueda (x:CHAR; t: ARRAY [CHAR]): Boolean;
FUNCTION Búsqueda (x:REAL; t: ARRAY[REAL]): Boolean;
Facilidad sintáctica orientada a los clientes.
Permite escribir el mismo código cliente usando diferentes implementaciones de cierto concepto.
¿Qué nos proporciona la sobrecarga?
¿ Resuelve “Variación en estructuras de datos y algoritmos”?
¿Resuelve “Independencia de la representación”?
En cada invocación “Busqueda(x,t)” cliente y compilador saben de que versión se trata.
“Independencia en la representación” exige poder escribir “Busqueda(x,t)” significando:
“Busca x en t usando el algoritmo adecuado, cualesquiera que sea la clase de colección ligada a t en tiempo de ejecución”
Genericidad
Posibilidad de definir módulos parametrizados, cuyos parámetros representan tipos.
Facilidad orientada a los creadores de módulos permite escribir el mismo código cuando se usa la misma implementación de cierto concepto, aplicado a diferentes tipos de objetos” Ej: Array [T], Lista[T]
Los módulos cliente deben instanciar el módulo genérico Ej: Array [Real], Lista[Figura],
Resuelve “variación en tipos”
Ejemplo de Genericidad
Package Tabla[T];
type ArbolBinario
record
info: T
izq, der: ArbolBinEnteros
end;
new: ArbolBinario begin … end;
añadir(t:ArbolBinario; x: T) begin … end;
existe(t:ArbolBinario; x: T): Boolean begin .. end
….
end
La genericidad resuelve:
Variación en tipos.
Los paquetes/modulos resuelve:
Rutinas relacionadas.
No se resuelve:
Variación en estructuras de datos y algoritmos.
Independencia de la representación.
Capturar similitudes entre un subgrupo de un conjunto de posibles implementaciones.
Conclusión
Descomposición Funcional
(Gp:) A
(Gp:) B
(Gp:) C
(Gp:) D
(Gp:) E
(Gp:) H
(Gp:) G
(Gp:) F
Secuencia
Bucle
Condicional
Inconvenientes de la Descomposición Funcional
Función principal: “Cima del sistema”
El “programa principal” es una propiedad volátil
Sistemas reales no tienen “cima”
Mejor la visión de un “conjunto de servicios”
Centrado en la interfaz
Primera pregunta: ¿Que hará el sistema?
La arquitectura del software debe basarse en propiedades más profundas.
Ordenación temporal prematura
Inconvenientes de la Descomposición Funcional
No favorece la reutilización
Se desarrollan elementos software para satisfacer necesidades específicas de otro elemento del nivel superior.
“Cultura del proyecto actual”
Las estructuras de datos son descuidadas
Funciones y datos deben jugar un papel complementario
Cuando un sistema evoluciona los datos son más estables que los procesos.
Ventajas de la Descomposición Funcional
Técnica simple, fácil de aplicar
Util para pequeños programas y describir algoritmos.
Buena para documentar diseños.
Facilita desarrollo sistemático de sistemas
Adecuada para dominar la complejidad
Descomposición basada en objetos
Los objetos son más estables que las funciones cuando el sistema evoluciona (Extensibilidad).
Tipos de objetos equipados con las operaciones asociadas (Reutilización).
El diseñador lista las operaciones aplicables a cierto tipo de objetos, especificando su efecto.
Se retrasa todo lo posible el orden en que se ejecutan las operaciones.
Desarrollo software OO
1. Encontrar tipos de objetos relevantes
2. Encontrar operaciones para tipos de objetos
3. Describir tipos de objetos
4. Encontrar relaciones entre objetos
5. Usar tipos de objetos para estructurar software
Conceptos Clave POO
Clase y Objeto
Clase: Atributos y métodos
Creación de clases: constructores e instanciación
Invocación de métodos
Atributos y métodos de clase
Ocultación de información
Tipos referencia, asignación, aliasing y copia de objetos
Concepto de Metaclase
Relaciones entre clases: clientela y herencia
Tipos de herencia
Polimorfismo y ligadura dinámica
Clases y Objetos
Una clase es un módulo y un tipo de dato:
Módulo (concepto sintáctico)
Mecanismo para organizar el software (sintáctico)
Encapsula componentes software
Tipo (concepto semántico)
Mecanismo de definición de nuevos tipos de datos: describe una estructura de datos (objetos) para representar valores de un dominio y las operaciones aplicables.
Combinación módulo-tipo
“Los servicios proporcionados por una clase, vista como un módulo, son precisamente las operaciones disponibles sobre las instancias de la clase, vista como un tipo”.
Como cada módulo es un tipo, cada operación del módulo es relativa a cierta instancia del tipo
TAD y Clase
Teoría
TAD
{Operaciones: Sintaxis
y Semántica}
Software
Clase
{Elegir representación e
implementar operaciones}
Clases: Ejemplo
Al modelar un banco, encontramos objetos “cuenta”.
Todos los objetos “cuenta” tienen unas propiedades comunes:
saldo, titular, código, reintegro, ingreso, …
Definimos una clase Cuenta.
Clases del dominio y clases de diseño/implementación
Componentes de un clase
Atributos
Determinan una estructura de almacenamiento para cada objeto de la clase
Rutinas (Métodos)
Operaciones aplicables a los objetos
Único modo de acceder a los atributos
Ejemplo: Al modelar un banco, encontramos objetos “cuenta”.
Todos los objetos “cuenta” tienen propiedades comunes:
atributos: saldo, titular, …
operaciones: reintegro, ingreso, …
Definimos una clase CUENTA.
Cada objeto es instancia de una clase
(Gp:) Clase Cuenta
(Gp:) Objeto Cuenta
(Gp:) Objeto Cuenta
(Gp:) Objeto Cuenta
(Gp:) Objeto Cuenta
(Gp:) Instanciación
Cada objeto es instancia directa de una clase.
Una clase es una factoría de objetos
Estructura de datos
Cuenta oc
oc = new Cuenta()
Código
Constructores (C++ y Java)
Realizan la inicialización de un objeto tras la creación.
Un constructor
procedimiento especial con el mismo nombre que la clase.
Se debe invocar cuando se crea un objeto de la clase con el operador new
En C++ también cuando se declara una variable.
Pueden tener modificadores de acceso
Mensajes
Mecanismo básico de la computación OO.
Invocación de la aplicación de un método sobre un objeto.
La modificación o consulta del estado de un objeto se realiza mediante mensajes.
Formado por tres partes
Objeto receptor
Selector o identificador del método a aplicar
Argumentos
Semántica mensajes
Sea el mensaje x.f, su significado es:
“Aplicar el método f sobre el receptor x, efectuando el paso de parámetros”
¡NO CONFUNDIR CON LA INVOCACIÓN DE UN PROCEDIMIENTO!
Variables y métodos de Clase
Compartida por todas las instancias de una clase.
Registrar valor común a todas las instancias
Ejemplos para una clase Cuenta:
Interés, Coste tarjeta, Último código asignado
¿Cuándo se inicializa?
Puede ser accedida por métodos de instancia y de clase
Los métodos de clase no deberían acceder a variables de instancia
Clases y Ocultación de Información
Ocultamiento información importante para conseguir arquitecturas flexibles y coherentes.
Interface vs. Implementación:
Un cliente sólo conoce la interface.
Sólo los métodos de la clase deberían poder acceder a sus atributos.
Cada lenguaje OO (Eiffel, C++, Java, Smalltalk) presenta diferencias en cuanto al ocultamiento de información.
Tipos referencia
Los posibles valores de una entidad (atributo, parámetro, …) son referencias a objetos potenciales que pueden ser creados en tiempo de ejecución a través, siempre, de instrucciones de creación explícitas.
Una referencia puede encontrarse en uno de dos estados posibles
No ligada: Void (Eiffel) o null (Java)
Ligada a un objeto
Las referencias son “punteros domesticados”.
Void es un estado (null es un literal) mientras que “nil” (en Pascal) o “null” (en C) son valores de tipo puntero.
Ventajas de los tipos referencia
Más eficiente para manejar objetos complejos.
Soporte para definir estructuras de datos recursivas.
Soporte del polimorfismo.
Los objetos son creados cuando son necesarios.
Permite la compartición de un objeto (integridad semántica).
DESVENTAJA: “Aliasing”
¡Cuidado con el Aliasing!
(Gp:) oa
(Gp:) ob
oa:= ob
(Gp:) ob
(Gp:) oa
La asignación no implica copia de valores sino de
referencias
Asignación
Solución: Copia de objetos
Copia superficial
Se copian los valores de cada campo del objeto origen oy en el objeto destino ox; ox y oy comparten referencias.
Soportada por defecto y puede redefinirse para una clase concreta.
Copia profunda
Se crea un objeto con una estructura idéntica al objeto origen.
No hay compartición de referencias
No suele ser soportada por defecto
Metaclases
Una clase puede ser considerada un objeto:
¿Cuál es su clase?
Metaclase
Clase que describe clases, sus instancias son clases.
Propiedades: lista de atributos, lista de variables de clase, lista de métodos, lista de métodos de clase.
Java y Smalltalk tienen metaclases
Útil en programación avanzada, cuando se manejan entidades software, p.e. depuradores, inspectores, browsers,..
Relaciones entre clases
Clientela
Una clase A es cliente de una clase B, si A contiene una declaración en la que se establezca que cierta entidad (atributo, parámetro, variable local) e es de tipo B (e:B)
Ejemplo:
(Gp:) titular: Persona
(Gp:) CUENTA
(Gp:) PERSONA
(Gp:) “Cuenta es cliente de Persona”
Herencia
Una clase es una versión especializada de otra existente
Ejemplo:
(Gp:) Cuenta
(Gp:) CuentaAhorro
(Gp:) CuentaCorriente
Herencia
(Gp:) PUBLICACION
(Gp:) LIBRO
(Gp:) REVISTA
(Gp:) LIBRO_TEXTO
(Gp:) INVESTIGACION
(Gp:) MAGAZINE
(Gp:) FIGURA
(Gp:) POLIGONO
(Gp:) CIRCULO
(Gp:) RECTANGULO
La herencia organiza las clases en una estructura jerárquica:
Jerarquías de clases
Ejemplos:
No es tan solo un mecanismo para compartir código.
Consistente con el sistema de tipos del lenguaje
Herencia
Puede existir una clase “raíz” en la jerarquía de la cual heredan las demás directa o indirectamente.
Incluye todas las características comunes a todas las clases
Eiffel: clase ANY
Smalltalk: clase Object
Java: clase Object
C++: no existe
Herencia
Si B hereda de A entonces B incorpora la estructura (atributos) y comportamiento (métodos) de la clase A, pero puede incluir adaptaciones:
-B puede añadir nuevos atributos
-B puede añadir nuevos métodos
-B puede REDEFINIR métodos
-B puede renombrar atributos o métodos
– B puede implementar un método diferido en A
…
Adaptaciones dependientes del lenguaje
(Redefinición disponible en cualquier LOO)
(Gp:) Refinamiento: Extender el uso original
Reemplazo: Mejorar la implementación
Polimorfismo
Es restringido por la herencia
Importante para escribir código genérico
Sea las declaraciones:
ox: X; rutina1 (oy:Y)
En un lenguaje con monomorfismo (Pascal, Ada, ..) en t.e. ox y oy denotarán valores de los tipos X e Y, respectivamente.
En un lenguaje con polimorfismo (Eiffel, C++, ..) en t.e. ox y oy podrán estar asociados a objetos de varios tipos diferentes:
tipo estático vs. tipo dinámico
Tipo estático y tipo dinámico
Tipo estático:
Tipo asociado en la declaración
Tipo dinámico:
Tipo correspondiente a la clase del objeto conectado a la entidad en tiempo de ejecución
Conjunto de tipos dinámicos:
Conjunto de posibles tipos dinámicos de una entidad
oa: A; ob: B; oc; C;
te(oa) = A ctd(oa) = {A,B,C,D,E,F}
te(ob) = B ctd(ob) = {B, D, E}
te(oc) = C ctd(oc) = {C,F}
(Gp:) A
(Gp:) E
(Gp:) D
(Gp:) C
(Gp:) B
(Gp:) F
Ejemplo:
Conexión polimorfa
Cuando el origen y el destino tiene tipos diferentes:
a) asignación:
p := r; — p es una entidad polimorfa
b) paso de parámetros:
f (p:POLIGONO) is do … end — f es una rutina polimorfa
Sólo se permite para entidades destino de tipo referencia
(Gp:) (POLIGONO)
(Gp:) p
(Gp:) (antes)
(Gp:) (después)
(Gp:) (RECTANGULO)
(Gp:) r
(Gp:) ?
p:POLIGONO; r:RECTANGULO
Tipos de polimorfismo
Real
Paramétrico (“lista de T”)
Inclusión:
Basado en la herencia
una función y varias interpretaciones diferentes
Aparente
Sobrecarga
varias funciones todas con el mismo nombre
Ejemplo polimorfismo paramétrico:
long (l:lista): integer
if l=nil then long:=1
else long:= 1 + long(cola(l))
Sobrecarga
Es el nombre de la función lo que es polimórfico
Se resuelve en tiempo de compilación, según la signatura de la rutina.
No es necesario que exista similitud semántica.
En los lenguajes OO puede existir sobrecarga
dentro de una clase
entre clases no relacionadas (es fundamental)
Polimorfismo y código genérico
Estructuras de datos polimórficas:
Pueden contener instancias de una jerarquía de clases
Ejemplo: fig: ARRAY [FIGURA]
p: POLIGONO;
r: RECTANGULO;
c: CIRCULO;
t:TRIANGULO;
!!p; !!r; !!c; !!t;
fig.put (p,1);
fig.put (r,2);
fig.put (c,3);
fig.put (t,4); …
(Gp:) 1
(Gp:) 2
(Gp:) 3
(Gp:) 4
fig
Genericidad
¿Cómo escribir una clase que represente una estructura de datos y que sea posible almacenar objetos de cualquier tipo?
Pila-Enteros
Pila_Libros ? Pila de ?
Pila_Figuras
….
Necesidad de reconciliar reutilización con el uso de un lenguaje tipado.
Herencia
ColeccionEntero
ListaEntero
ListaCircularEntero
ColeccionTarea
GrafoTarea
RedTarea
class ListaEntero inherit ColeccionEntero feature
numElements: Integer is do ..
añadir (i: Integer, v:Integer) is do ..
iesimo (i:Integer): Integer is do ..
buscar (v:Integer): Boolean is do ..
…
end
¿Cómo asociar a v un tipo pero sin hacer que
la clase sea dependiente del tipo de objeto
almacenado?
Genericidad
Coleccion [G]
Lista [G]
ListaCircular [G]
class Lista [G] feature
numElements. Integer is do ..
añadir (i: Integer, v:G) is do ..
iesimo (i:Integer): G is do ..
buscar (v:G): Boolean is do ..
…
end
miLista1: Lista [Integer]
miLista2: Lista [Punto]
Genericidad
Posibilidad de parametrizar las clases; los parámetros son tipos de datos.
Facilidad útil para las clases que representan estructuras de datos generales: TIPO BASE ES UN PARAMETRO
class ARRAY [G], class PILA [G], class LISTA [G], …
Orientada a los creadores de clases
 Página anterior | Volver al principio del trabajo | Página siguiente  |